docs/adr/0010-security-contacts-worker.md:43

• Tier D is described as implemented, but none of the named extractor files exist and processBatch.ts:50-57 registers only A1 through B2. No code under security-contacts emits a tier-D contact. Either add the D extractors before accepting this ADR or clearly mark this tier and all dependent claims as proposed/unimplemented.

| D | Top-3 committers (last 90 days) + repo owner profile; static Go ecosystem fallback | `topCommitters.ts`, `repoOwner.ts`, `registry/go.ts` |

docs/adr/0010-security-contacts-worker.md:67

• The documented Go fallback is not implemented: there is no registry/go.ts, no golang.org/g.co/vulnz contact source, and extractors/registry/index.ts:19-28 explicitly omits Go from FETCHERS. As written, Go repos can still receive an empty result, contrary to this accepted decision.

- **Go packages get a static ecosystem fallback**: Go has no registry manifest carrying contact
  metadata (the module proxy and pkg.go.dev expose none), so the Go fetcher makes no HTTP call and
  always emits two tier-D `security-team` contacts per the Go security policy —
  `security@golang.org` and the `https://g.co/vulnz` report form. At tier D they never outrank a
  real repo-level contact, and they don't suppress the committers/owner gate (which only checks
  for usable contacts above tier D), so a Go repo is never left with an empty answer.

docs/adr/0010-security-contacts-worker.md:207

• The worker exposes this on-demand workflow, but no API code invokes it. Repository-wide references to ingestSecurityContactsForPurlWorkflow are limited to its definition and worker re-export; getPackage.ts:41-54 simply returns null when contacts have not been evaluated. Please wire the API cache-miss path to the packages Temporal client, or document that the caller integration is still pending rather than saying the request triggers ingestion.

On the read side, the API contract distinguishes **`securityContacts: null`** (repo never
evaluated — `contacts_last_refreshed IS NULL`, which is what triggers the on-demand ingest) from
**`[]`** (evaluated, nothing found — no re-ingest until the daily retry). `packageConfidence` is
derived at read time as the band of the highest contact score, not stored.

docs/adr/0010-security-contacts-worker.md:280

• The single-writer assumption already has a second writer in this ADR: the on-demand workflow calls writeContacts independently of the scheduled batch. ScheduleOverlapPolicy.SKIP only serializes schedule actions; it does not prevent on-demand executions (or concurrent cache misses) from writing the same repo. Record and implement a per-repo serialization/locking strategy, or explicitly accept and analyze the concurrent-write behavior.

- **Single-writer assumption** — `writeContacts` takes no lock; correctness relies on the Temporal
  schedule (SKIP overlap) and heartbeat-based supersession keeping one writer per repo. A future
  second caller (e.g. a backfill script) must respect this or add locking.

docs/adr/0010-security-contacts-worker.md:28

• The on-demand workflow exists in the worker, but the Akrites API does not invoke it. Repository-wide references to ingestSecurityContactsForPurlWorkflow are limited to the workflow definition/export and this ADR, while getPackage.ts only converts a null refresh timestamp to securityContacts: null. Wire the cache-miss path through getPackagesTemporalClient() or document this as unimplemented rather than an accepted behavior.

comes back empty, 24 h execution timeout across the chain), plus a separate **on-demand
single-purl workflow** invoked by the akrites API when it hits a never-evaluated repo. Each repo

docs/adr/0010-security-contacts-worker.md:39

• securityContactsFile.ts probes only the root SECURITY_CONTACTS path (PATH = 'SECURITY_CONTACTS' and a single contents request at lines 11 and 58-60); it does not discover an OWNERS file. Remove OWNERS from the implemented source list unless support is added.

| A3 | `SECURITY_CONTACTS` / `OWNERS` (k8s-style) | `securityContactsFile.ts` |

docs/adr/0010-security-contacts-worker.md:280

• The current design already has a second writer: the API-triggerable on-demand workflow can process the same repo as the scheduled batch, and ScheduleOverlapPolicy.SKIP only coordinates runs of the schedule. Neither path takes a per-repo lock, so the asserted single-writer guarantee is not provided and concurrent soft-delete/upsert transactions can produce nondeterministic last-writer results. Treat the on-demand path as an existing concurrency risk and add per-repo serialization/locking rather than deferring this to a hypothetical future caller.

- **Single-writer assumption** — `writeContacts` takes no lock; correctness relies on the Temporal
  schedule (SKIP overlap) and heartbeat-based supersession keeping one writer per repo. A future
  second caller (e.g. a backfill script) must respect this or add locking.